@ZivLow
when wifi_csi_report returns len = 0, does buffer contains header with csi_data_len = 0

in such case we should add header without check of len > 0

@ZivLow @jwei5
We observed, CSI header length was 44 (trig_flag added in header) when multi station is enabled. Hence adding a constant 43 cannot be done.

An alternate solution can be:
wifi_csi_report fills in 3rd parameter "len", complete buffer length including header.
in case data length is required, header can be parsed for data length

Hi @vibhor-m , if wifi_csi_report() returns SUCCESS, len will always return the CSI packet length without the header length, and it should not be 0.
But in the abnormal event that it does report 0, the buffer will still contain the CSI header

@ZivLow @jwei5 We observed, CSI header length was 44 (trig_flag added in header) when multi station is enabled. Hence adding a constant 43 cannot be done.

An alternate solution can be: wifi_csi_report fills in 3rd parameter "len", complete buffer length including header. in case data length is required, header can be parsed for data length

Hi @vibhor-m , we would like to clarify that the CSI header length is based on the CSI driver's version. This means that once RTK updates the driver to support multi station CSI, the header length will be 44 regardless of whether the multi-station feature is being used.

Could I check whether there will be a scenario where rtk_wifi_csi.c is not in sync with our CSI driver's version?

Thank you for explanation. rtk_wifi_csi.c will always be in sync with CSI Driver version. I agree with you.